Service Extension Callout (Envoy external processing) #2895
Conversation
e-n-0
force-pushed
the
flavien/service-extensions
branch
from
1a34984
to
89773db
Compare
![datadog-datadog-prod-us1[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
| uses: docker/setup-qemu-action@v3 | ||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
| id: go | ||
|
|
||
| - name: Set up QEMU | ||
| uses: docker/setup-qemu-action@v3 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
| uses: docker/setup-buildx-action@v3 | ||
|
|
||
| - name: Login to GitHub Container Registry | ||
| uses: docker/login-action@v2 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
| @@ -0,0 +1,40 @@ | |||
| name: Publish Service Extensions Callout images packages | |||
There was a problem hiding this comment.
🟠 Code Vulnerability
No explicit permissions set for at the workflow level (...read more)
Check the permissions granted to jobs
Datadog’s GitHub organization defines default permissions for the GITHUB_TOKEN to be restricted (contents:read, metadata:read and packages:read).
Your repository may require different setup, but please consider defining permissions for each job following the least privilege principle to restrict the impact of a possible compromission.
You can find the list of all possible permissions in Workflow syntax for GitHub Actions - GitHub Docs. Please note they can be defined at the job or the workflow level.
| password: ${{ secrets.GITHUB_TOKEN }} | ||
|
|
||
| - name: Build and push | ||
| uses: docker/build-push-action@v6 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Set up Go 1.22 | ||
| uses: actions/setup-go@v2 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
e-n-0
force-pushed
the
flavien/service-extensions
branch
4 times, most recently
from
40d4289
to
594023c
Compare
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Set up Go 1.22 | ||
| uses: actions/setup-go@v5 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
e-n-0
force-pushed
the
flavien/service-extensions
branch
2 times, most recently
from
fcbd354
to
a587a09
Compare
BenchmarksBenchmark execution time: 2024-10-16 16:38:35 Comparing candidate commit a799cf0 in PR branch Found 2 performance improvements and 3 performance regressions! Performance is the same for 54 metrics, 0 unstable metrics. scenario:BenchmarkInjectW3C-24
scenario:BenchmarkStartRequestSpan-24
scenario:BenchmarkTracerAddSpans-24
|
e-n-0
force-pushed
the
flavien/service-extensions
branch
8 times, most recently
from
bdf08fd
to
1ef1070
Compare
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🟠 Code Vulnerability
Workflow depends on a GitHub actions pinned by tag (...read more)
Pin third party actions by hash, or at least by tag for trusted sources
When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a git ref (a branch name, a git tag, or a commit hash).
No pinned git ref means the action will use the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.
Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.
Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
e-n-0
force-pushed
the
flavien/service-extensions
branch
5 times, most recently
from
3940197
to
0a1ae11
Compare
e-n-0
force-pushed
the
flavien/service-extensions
branch
8 times, most recently
from
6985de0
to
0c57ea1
Compare
e-n-0
force-pushed
the
flavien/service-extensions
branch
from
3b13cd1
to
e7e418b
Compare
e-n-0
force-pushed
the
flavien/service-extensions
branch
from
3aaea03
to
045ef15
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| Response: &extproc.ProcessingResponse_ImmediateResponse{ | ||
| ImmediateResponse: &extproc.ImmediateResponse{ | ||
| Status: &v32.HttpStatus{ | ||
| Code: v32.StatusCode(currentRequest.statusCode), |
Check failure
Code scanning / CodeQL
Incorrect conversion between integer types High
Show autofix suggestion
Hide autofix suggestion
Copilot Autofix AI about 1 hour ago
To fix the problem, we need to ensure that the integer value parsed from the string does not exceed the bounds of int32 before converting it. This can be achieved by using strconv.ParseInt with a bit size of 32, which directly parses the string into an int32 value, or by adding explicit bounds checking after using strconv.Atoi.
The best way to fix this without changing existing functionality is to replace the strconv.Atoi call with strconv.ParseInt specifying a 32-bit size. This ensures that the parsed value is within the bounds of int32.
| @@ -252,3 +252,7 @@ | ||
|
|
||
| currentRequest.statusCode, err = strconv.Atoi(statusCodeStr) | ||
| parsed, err := strconv.ParseInt(statusCodeStr, 10, 32) | ||
| if err != nil { | ||
| return nil, status.Errorf(codes.InvalidArgument, "Error parsing response header status code: %v", err) | ||
| } | ||
| currentRequest.statusCode = int(parsed) | ||
| if err != nil { |
What does this PR do?
Motivation
Reviewer's Checklist
Unsure? Have a question? Request a review!